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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 2 of a multi-part deliverable covering Methods and Protocols for security in TIPHON 
Release 4, as identified below: 

Pai-tl: "Threat Analysis"; 

Part 2: " Counter Measures ' ' . 
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Scope 



The present document defines by means of an information model, a functional entity behavioural model, and by 
validated SDL a model of the abstract behaviour of each service and service capability identified as being essential in 
TIPHON R4. 

The present document defines by means of meta-protocol, algorithm boundary conditions, and guidance text the 
security countermeasures identified in TS 102 165-1 [1]. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 101 877 [2] and TS 101 878 [3] apply. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 101 877 [2], TS 101 878 [3] and the following 
apply: 

CK Cipher Key 

FE Functional Entities 

FES For Further Study 

KSG Key Stream Generator 

KSS Key Stream Segment 

MSC Message Sequence Chart 

PDU Protocol Data Unit 

RSO Random Seed 

SDU Service Data Unit 

SpoA Service point of Attachement 

TpoA Transport point of Attachement 

TV? Time Variant Parameter 



Provision of counter-measures in TIPHON 



4.1 Required security services 



In TS 102 165-1 [1] the threats to a TIPHON system have been analysed and a set of recommended countermeasures 
identified that when implemented will reduce the overall risk to users of TIPHON systems. A subset of these 
countermeasures has been identified as essential to counter most threats. 

The following security services are identified in [1] as required to minimize the risk to TIPHON to an acceptable level 
and are required to be standardized. 

Al = Authentication of the terminal by the registrar (home of the user profile); 

A2 = Authentication of the registrar by the terminal; 

A3 = Authentication of the terminal by the Service point of Attachment (SpoA); 

A4 = Authentication of the SpoA by the terminal; 

A5 = Authentication of the SpoA by the registrar; 

A6 = Authentication of the registrar by the SpoA; 

CI - C5 = Access control to services, to service data in databases, to data in terminals, 

and to the service provider's software and hardware, respectively; 
El = Confidentiality of user communication on the access interface; 
E2 = Confidentiality of signalling on the access interface; 

- E3 = Confidentiality of signalling between SpoA entities; 

- E6 = Confidentiality of TlPHON-id on signalling interfaces; 

- E7 = Confidentiality of signalling between SpoA and Registrar; 
PI = Bill limitations; 

P2 = Secure billing administration; 

P3 = Subscriber and terminal management; 

P9 = Security related reports to the service providers; and 

PIO = Secure subscription process. 

The implementation method of these countermeasures can reduce the risk. However each countermeasure introduces 
new threats to the system by adding complexity, and different implementations of the same conceptual countermeasure 
may introduce different levels of risk. In some instances a specific countermeasure cannot be applied to a particular 
technology. 
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4.2 Location of standardization of security services 

Not all security services are standardized in the present document. Table 1 identifies the location of standardized 
countermeasures. 

Table 1 : Where counter-measures are provided in TIPIHON specifications 



Security service 


Form of standardization 


Location 


A1 


Meta-protocol and algorithm specification 


The present document, 
clause 6 


A2 


IVIeta-protocol and algorithm specification 


The present document, 
clause 7 


A3 


IVIeta-protocol and algorithm specification 


The present document, 
clause 8 


A4 


IVIeta-protocol and algorithm specification 


The present document, 
clause 9 


A5 


IVIeta-protocol and algorithm specification 


The present document, 
clause 10 


A6 


Meta-protocol and algorithm specification 


The present document, 
clause 1 1 


C1 


IVIeta-protocol specification 


TS101 882-2 


C2-C4 


FFS 


TBD 


E1 


Algorithm specification and application guideline 


The present document, 
clause 12 


E2 


Algorithm specification and application guideline 


The present document, 
clause 12 


E3 


Algorithm specification and application guideline 


The present document, 
clause 12 


E6 


Application guideline 


The present document, 
clause 12 


E7 


Algorithm specification and application guideline 


The present document, 
clause 12 


P1, P2, P3, P9, P10 


Management framework requirements 


TS101 303 



Services Al and A5 are functionally identical and are described only once. In both cases the entity being authenticated 
has direct access to the shared secret, whereas the entity performing the authentication (the registrar) maintains the key 
to identity relationship through a third party (the authentication centre). The specific algorithms invoked in Al and A5 
may be different. 

Services A2 and A6 are functionally identical and are described only once. The specific algorithms invoked in A2 and 
A6 may be different. 

Services A3 and A4 are described in the present document as a single mutual authentication service A34. 



Authentication counter-measures 



5.1 



Introduction 



5.1.1 Description 

The primary purpose of the authentication service is to counter masquerade attacks. This may prevent attack on the 
system by determining that the user is legitimate, and may prevent an attack on the user by determining that the system 
is legitimate. The authentication services when successfully performed provide the first step in provision of access 
control to services (CI). 

The authentication services are specified with respect to the entities and identities shown in figure 1 . 
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NOTE 1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 
NOTE 6 
NOTE 7 
NOTES 
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A single user may be associated with many registrant-ids 

A registrant-id sliall be associated with only one user 

A registrant-id shall be associated with only one registrar 

A registrar may be associated with many registrant-ids 

A service may be associated with many SpoAs 

In any registration instance a service shall be associated with only one SpoA 

An SpoA shall be associated with only one Service 

A registrant-id may be associated with many Services 

Figure 1 : Ordinal relations in TIPHON 



5.2 Keying policy in TIPHON 
5.2.1 Release 4 

In TIPHON Release 4 the policy towards keying will assume only symmetric keying methods. This method requires 
pre-arrangement between the authenticating entities but ensures that the authentication framework is able to provide a 
mapping to existing terminals which employ strong authentication (e.g. GSM, 3GPP-UMTS, DECT, TETRA). 

In order to consider the authentication of the principal participants of TIPHON the following constraints on keying arise 
from the relations shown in figure 1 . 

• Registrant to Registrar shall use symmetric key authentication methods. 

• Registrar to SpoA shall employ symmetric key authentication methods. 

• Registrant to SpoA shall employ a symmetric session key to achieve authentication. 
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Registrant- 
id 



Secret Key K 
(A1&A2) 



Session 

key 

exchange 

(A3&A4) 



Registrar 
(AuC) 
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Figure 2: Key relationships in TIPHON 
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As a user may have many registrant-ids the user should be able to identify which to use and access to the registrant-id 
should be authenticated using a Personal Identification Number (PIN) or similar. The authentication service (A7) that 
provides for this protection of this identity is not described in this edition of the present document. 

The symmetric keying authentication methods will be based upon the provisions described in ISO/IEC 9798-2 [5]. 

5.2.1 .1 Review of service attributes 

The authentication protocol should have the following properties: 

• Bi-directional challenge-response type; 

• Able to be initiated either explicitly or as part of the registration procedure; 

• Able to be initiated by the terminal or the network; 

• The recipient of the first authentication demand may instigate mutual authentication by use of a mutual 
authentication indicator, and by sending its challenge together with the response to the first challenge; and 

• Where authentication is initiated as part of the registration the authentication timer TA shall always be less 
than or equal in value to any registration timer. 

5.2.2 Release 5 and future 

In TIPHON Release 5 and onwards the policy towards keying will encompass both symmetric and asymmetric keying 
methods. 

The introduction of asymmetric methods may better counter the threats imposed by soft terminals and replace methods 
currently available that are based upon weak authentication methods (e.g. user-name and password). The public keying 
authentication methods will be based upon the provisions described in ISO/IEC 9798-3 [6]. 

6 A1 = Authentication of the terminal 

6.1 Purpose 

Service Al offers strong authentication of a terminal to minimize the risk of masquerade of a terminal to the network. 

6.2 Definition 

The terminal shall contain a unique identity known to the registrar and authentication shall confirm this identity through 
proof of knowledge of a secret shared by the registrar and the terminal. This countermeasure is the corollary of A2. 

6.3 Description 

NOTE: The mechanism here is similar to the three pass authentication method defined in ISO/IEC 9798-2 [5]. 

The authentication method described is a symmetric secret key type using a challenge-response protocol. In this method 
one secret, the authentication key (K-Al), is shared by each of the authenticating parties, and there should be strictly 
two parties with knowledge of the secret. Authentication is achieved by the parties proving to each other knowledge of 
the shared secret. The authenticating parties are the authentication centre attached to the registrar and the terminal 
representing the user. 

The following sequence of events illustrates the requirement: 

1) The authentication centre shall generate a random challenge and send it to the terminal. 

2) Both parties shall generate the intermediate result Intermediate-Result from algorithm Al-1 using the random 
challenge and K-Al as inputs. 
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3) The terminal shall generate a random seed for the second stage of the authentication exchange. 

4) The terminal shall generate the cryptographic response response using algorithm Al-2 with inputs seed and 
Intermediate-Result. 

5) The terminal shall send the random seed and the response to the authentication centre. 

6) Upon receipt the authentication centre shall generate the expected cryptographic response using the received 
random seed and the pre-determined Intermediate-Result with algorithm Al-2. In addition Al-2 should 
generate an encryption key derived in this exchange for use in later confidentiality services. 

7) The authentication centre shall compare the expected cryptographic response and the received response, if 
they are the same the terminal has proven knowledge of K-Al. 

In addition to the above event sequence the protocol should be able to confirm randomness of the challenge and of the 
second stage seed. 



Terminal 



Received 
Challenge K-A1 



AM 



Generated 
Seed 

± 



I It-Result 



A1-2 



Response 



CryptoKey 



Challenge 



Seed. Response 



Result 



AuC 



Generated 
Challenge K-A1 



AM 



Received 
Seed 



irt-Result 



A1-2 



T 
X-Response 



CryptoKey 



Response 
± 



A1-3 

-^ 

Result 



NOTE: The split of the authentication algorithms allows K-A1 and algorithm A1-1 to be stored and maintained 
separately (remotely) from the location of A1-2. 

Figure 3: Authentication service A1, algorithm invocations 



6.4 



Procedures 



6.4.1 Provision/withdrawal 

Authentication shall always be available. 
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6.4.2 Normal procedures 

Authentication shall always be activated. 

6.4.2.1 Invocation and operation 

Authentication may be invoked on one or more of the following events: 

on registration to TIPHON; 

on change of physical point of attachment; 

on change of logical point of attachment; 

on demand by the user through some terminal function; and 

on demand by the authentication centre. 

The registration and service attachment service defined in TS 101 882-2may be used as the master service for 
invocation of Al. 

6.4.3 Exceptional procedures 

6.4.3.1 Activation/deactivation/registration/interrogation 

Not applicable. 

6.4.3.2 Invocation and operation 

If the expected response is not equal to the received response authentication is not proven and services A3, A4, A5 and 
A6 shall not be invoked. A network may reattempt service Al, however repeated failure may be considered as an attack 
on the algorithms and should be deterred by denying access to the initiator of the authentication. 

6.5 Interactions with other TIPHON services 

The authentication services are linked to the registration service and shall be operated in parallel to them. 
The authentication services shall provide keying material for the confidentiality services El, E2 and E7. 
The authentication services shall provide the basis for the access control service CI. 

6.6 Interworking considerations 

The authentication algorithms used by each of the participant entities have to be matched. 
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6.7 Functional entity model 
6.7.1 Description of model 

Figure 4 shows the FEs and the relationships between them. 




Figure 4: Relationships between functional entities for authentication service A1 



Where: 



TIPHON user 



The entity representing the user who may be informed of the progress of an authentication exchange. 



A1-FE1 



The agent of the user being authenticated, contains algorithms A1 -1 and A1 -2. 



A1-FE2 



The local authorizing agent, contains algorithm A1-2 and A1-3. 



A1-FE3 



Holder of K, the shared secret upon which authentication is based, contains algorithm A1-1 . 



The information flows belonging to service Al are: 

• AlAuth(ra) 

• AlAuthResult (ra) 

• AlChallengeRequest (rb) 



6.8 



Information flows 



6.8.1 Definition of information flows 



6.8.1.1 



Relationship ra 



6.8.1.1.1 



AlAuth (req/ind/resp/conf) 



Al Auth is a confirmed information flow that shall be sent across relation ra from FE2 to FEl to indicate a request for 
authentication. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


Challenge 




M 


- 


Result 


Success 

Key not recognized 


- 


M 


Response 




- 


(see note) 


Seed 




- 


(see note) 


NOTE: Provided if result is success 
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AlAuth-ri : : = 


SEQUENCE 


userld 


AuthenticIdType, 


challenge 
} 


ChallengeType 


AlAuth-rc : := 


SEQUENCE 


result 


AuthResultType, 


response 


ResponseType OPTIONAL 


seed 


SeedType OPTIONAL 



6.8.1.1.2 



AlAuthResult 



Al AuthResult is an unconfirmed information flow that shall be sent across relation ra from FE2 to FEl to indicate the 
result of an authentication. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


Result 


Success 
Fail 


M 


- 



AlAuthResult-ri 



SEQUENCE 



userld AuthenticIdType, 

result BOOLEAN — TRUE equals success, FALSE equals fail 



6.8.1.2 Relationship rb 



6.8.1.2.1 



Al ChallengeRequest 



A 1 Challenge Request is a confirmed information flow that shall be sent across relation rd from FE2 to FE4 to request 
the random generated challenge and intermediate result. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


Result 


Success 

Userld not known 

Key not available 




M 


GeneratedChallenge 




- 


(see note) 


Intermediate Result 




- 


(see note) 


NOTE: Provided if result is success. 



AlChallengeRequest-ri ::= SEQUENCE 
{ 

userld AuthenticIdType 
} 

AlChallengeRequest-rc ::= SEQUENCE 

{ 

result AuthResultType, 

generatedChallenge ChallengeType OPTIONAL, 
intermediateResult IntResType OPTIONAL 
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6.9 Information flow sequences 

This clause specifies the information flow sequences for the authentication service. 

NOTE 1 : The information flow sequences are produced with a MSC editor; however, the scenarios are not MSCs 
but information flow sequences as defined in ITU-T Recommendation 1.130 [4]. 

NOTE 2: In accordance with the ITU-T Recommendation 1.130 [4] the invoking side is placed as the leftmost entity 
in the information flow sequences. 

The step D for authentication shall provide signalling procedures in support of the information flow sequences specified 
in this clause. In addition, signalling procedures should be provided to cover other sequences arising from error 
situations, interactions with simple call, interactions with registration, different topologies, etc. 

In the information flow sequences, authentication information flows are represented by arrows. 

The following information flow sequences are intended as guidance in further development. 
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6.9.1 Information flows in A1 



6.9.1.1 



Normal behaviour 



MSC A1 



A1 FE1 



1_ 


FE2 




A1_ 


FE3 








201 








A1Challenge_req_ind 






(Userld) 








301 



202 



A1Auth_req_ind 



101 



102 



103 



{ Userld, Challenge) 



104 



A1Auth_resp_conf 



(Result Seed, Response) 



203 



204 



205 



A1AuthResult_req_ind 



(Userld, Result) 



105 



302 



A1Challenge_resp_conf 



( Result, Challenge, IntermedlateResult) 



Figure 5: Authentication service A1 information flows 
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6.9.1.2 Exceptional behaviour 

6.9.1.2.1 Userld not recognized by A1 -FES 

MSC A1ExceptionFE3 



A1 FE1 



A1 FE2 



A1 FE3 



201 



A1C hal lenge_req_ind 



(Userld) 



206 



301 



303 



A1C hal lenge_res p_conf 



(Result) 



Figure 6: Information flow for exception where Userld not recognized by A1-FE3 
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6.9.1 .2.2 Key is not available at A1-FE1 



MSC A1ExceptionFE1 



A1 FE1 



101 



106 



A1Auth_resp_conf 



(Result) 



A1 FE2 



A1 FE3 



201 



A1C hal lenge_req_ind 



(Userld) 



202 



A1Auth_req_ind 



{ Userld, Challenge) 



207 



301 



302 



A1C hal lenge_res p_conf 



( Result, Challenge, IntermediateResult) 



Figure 7: Information flow for exception where key is not available at A1-FE1 

6.9.2 Functional entity actions 

Throughout the descriptions of FE actions, the following conventions are used to identify information flows: 

An information flow is referred to as a "request" at the FE that sends it and as an "indication" at the FE that 
receives it. 

The corresponding confirmation is referred to as a "response" at the FE that sends it and as a "confirmation" at 
the FE that receives it. 

The following FE actions shall occur at the points indicated in the information flow sequences of clause 6.9.1. 
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6.9.2.1 Actions of A1-FE1 



101 Al-FEl shall extract challenge from the received information flow and shall generate the 
intermediate result Intermediate-Result from algorithm Al-1 using the random challenge and 
K-Al as inputs. 

102 Al -FEl shall generate a random seed for the second stage of the authentication exchange. 

103 Al-FEl shall generate the cryptographic response response using algorithm Al-2 with inputs seed 
and Intermediate-Result. 

104 Al-FEl shall send the random seed and the response to A1-FE2 

105 Al -FEl shall extract the result from the received information flow and if TRUE shall be 
authenticated, if FALSE shall not be authenticated and inhibit any further processing. 

106 If K-Al is not available result shall be set to "Key not found" and sent to A1-FE2. 

6.9.2.2 Actions of A1-FE2 

201 A1-FE2 shall request A1-FE3 to start the authentication process by sending the identity of the 
entity to be authenticated in an Al Challenge information flow. 

202 On receipt of the response to action 201 A1-FE2 shall forward the received Challenge to Al-FEl 
using the AlAuth information flow. 

203 Upon receipt of the response to AlAuth A1-FE2 shall generate the expected cryptographic 
response (X-Response) using the received random seed and the previously received 
Intermediate-Result with algorithm Al-2. 

204 A1-FE2 shall compare X-Response and the received Response using algorithm Al-3 generating 
Result. If Result is TRUE then Al-FEl has been authenticated. 

205 A1-FE2 shall send Result to Al-FEl using information flow AlAuthResult. 

206 If the result from A1-FE3 is not success further processing shall stop. 

207 If the result from Al-FEl is not success further processing shall stop. 

6.9.2.3 Actions of A1 -FES 

301 A1-FE3 shall identify K-Al based on the identity received from A1-FE2 and shall generate a 
random challenge using it as input to algorithm Al-1 with K-Al to generate Intermediate-Result. 

302 A1-FE3 shall send Intermediate-Result and challenge to A1-FE2 using information flow 
Al ChallengeRequest_resp_conf. 

303 If action 301 cannot identify K-Al from the identity received FE3 shall set result to "Key not 
available", else is the userld received is not known FE3 shall set result to "UserlD not known" and 
shall send Result to A1-FE2 using information flow Al ChallengeRequest_resp_conf. 



6.9.3 Functional entity behaviour 



The behaviour specified in this clause is intended to illustrate typical FE behaviour in terms of information flows sent 
and received. 

The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T 
Recommendation Z. 100 [7]. 
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6.9.3.1 Behaviour of A1-FE1 

The behaviour of Al-FEl is shown in the SDL process diagram in figure 8. 



CD 




Figure 8: A1-FE1 process diagram 
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6.9.3.2 Behaviour of A1-FE2 

The behaviour of A1-FE2 is shown in the SDL process diagram in figure 9. 



CD 



Arbitrary event that starts A1 



FE action 2011, 



A1ChallengeRequest_ri 



WaitAI FE3Response 



A1ChallengeRequest_rc 



Success 



^^3ReSaJJ 
^^1^^ ISuccess 



FE action 202 





— 


PrepA1Auth_ri 


1 








— 


A1Auth_ri 


1 






1 , , 


— 


WaitAI FE1 Response 








> 


- 


A1Autii_rc 



<^flRegH^ 
^ ^ ISuccess 
Success 



FE action 203 



A1 2 



FE action 204, .. A1_3 



FE action 205, 



AlAutiiResult ri 



FE action 206 



\/,,, 



FE action 207 



Figure 9: A1-FE2 process diagram 
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6.9.3.3 Behaviour of A1-FE3 

The behaviour of A1-FE3 is shown in the SDL process diagram in figure 10. 



CD 



IDLE 



A1 ChallengeRequest_ri 



GetKey 



^KeyFotmd, 



GenChallenge 



SetASRes 



FE action 301 ; 



A1 1 



FE action 303 ; 



,lt 



3uildRespi:. 



FE action 302 



A1 ChallengeRequest_rc 



A1 Glial lengeRequest_rc 



IDLE 



IDLE 



Figure 10: A1-FE1 process diagram 

6.9.4 Allocation of functional entities to domains 

The possible allocation of FEs to TIPHON is shown in table 2. 

Table 2: Allocation of FEs to TIPHON domains 



Scenario 


A1-FE1 


A1-FE2 


A1-FE3 


1 


Terminal 


Home Service provider 


Home Service provider 


2 


Terminal 


Visited Service provider 


Home Service provider 


3 


Access network (terminal proxy) 


Home Service provider 


Home Service provider 


4 


Access network (terminal proxy) 


Visited Service provider 


Home Service provider 



A2 = Authentication of the registrar 



7.1 Purpose 



Service A2 offers strong authentication of the network (registrar) to the terminal to minimize the risk of masquerade of 
a network to the terminal. 



7.2 



Definition 



The terminal shall contain a unique identity that identifies the registrar and authentication shall confirm this identity 
through proof of knowledge of a secret shared by the registrar and the terminal. This countermeasure is the corollary of 

Al. 
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7.3 Description 



NOTE: The mechanism here is similar to the three pass authentication method defined in ISO/IEC 9798-2 [5]. 

The authentication method described is a symmetric secret key type using a challenge-response protocol. In this method 
one secret, the authentication key (K-A2), is shared by each of the authenticating parties, and there should be strictly 
two parties with knowledge of the secret. Authentication is achieved by the parties proving to each other knowledge of 
the shared secret. The authenticating parties are the authentication centre attached to the registrar and the terminal 
representing the user. 

The following sequence of events illustrates the protocol requirement: 

1) The terminal shall generate a random challenge and send it to the authentication centre. 

2) Both parties shall generate the intermediate result Intermediate-Result from algorithm A2-1 using the random 
challenge and K-A2 as inputs. 

3) The authentication centre shall generate a random seed for the second stage of the authentication exchange. 

4) The authentication centre shall generate the cryptographic response response using algorithm A2-2 with inputs 
seed and Intermediate-Result. 

5) The authentication centre shall send the random seed and the response to the terminal. 

6) Upon receipt the terminal shall generate the expected cryptographic response using the received random seed 
and the pre-determined Intermediate-Result with algorithm A2-2. In addition A2-2 should generate an 
encryption key derived in this exchange for use in later confidentiality services. 

7) The terminal shall compare the expected cryptographic response and the received response, if they are the 
same the authentication centre has proven knowledge of K-A2. 

In addition to the above event sequence the protocol should be able to confirm randomness of the challenge and of the 
second stage seed. 



Terminal 



Generated 
Challenge K-A2 



A2-1 



Received 
Seed 



I It-Result 



A2-2 



X-Response 



t 
CryptoKey 



Response 



A2-3 



T 



Result 



Challenge 



Seed, Response 



Result 



AuC 



Received 
Challenge K-A2 



A2-1 



Generated 
Seed 

± 



irt-Result 



A2-2 



T 
Response 



T 
CryptoKey 



NOTE: The split of the authentication algorithms allows K-A2 and algorithm A2-1 to be stored and maintained 
separately (remotely) from the location of A2-2. 

Figure 11: Authentication service A2, algorithm invocations 
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7.4 Procedures 

7.4.1 Provision/withdrawal 

Authentication shall always be available. 

7.4.2 Normal procedures 

Authentication shall always be activated. 

7.4.2.1 Invocation and operation 

Authentication may be invoked on one or more of the following events: 
on registration to TIPHON™; 
on change of physical point of attachment; 
on change of logical point of attachment; 
on demand by the user through some terminal function; and 
on demand by the authentication centre. 

7.4.3 Exceptional procedures 

7.4.3.1 Activation/deactivation/registration/interrogation 

Not applicable. 

7.4.3.2 Invocation and operation 

If the expected response is not equal to the received response authentication is not proven and services A3, A4, A5 and 
A6 shall not be invoked. A terminal may reattempt service A2, however repeated failure may be considered as an attack 
on the algorithms and should be deterred by denying access to the initiator of the authentication. 

7.5 Interactions with other TIPHON services 

The authentication services are linked to the registration service and shall be operated in parallel to them. 
The authentication services shall provide keying material for the confidentiality services El, E2 and E7. 
The authentication services shall provide the basis for the access control service CI. 

7.6 Interworking considerations 

The authentication algorithms used by each of the participant entities have to be matched. 



7.7 Functional entity model 
7.7.1 Description of model 

Figure 12 shows the FEs and the relationships between them. 
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Figure 12: Relationships between functional entities for authentication service A2 



Where: 



TIPHON user 



The entity representing the user who may be informed of the progress of an authentication exchange. 



A2-FE1 



The agent of the user being authenticated, contains algorithms A2-1 , A2-2 and A2-3. 



A2-FE2 



The local authorizing agent, contains algorithms A2-2 and A2-3. 



A2-FE3 



Holder of K, the shared secret upon which authentication is based, contains algorithm A2-1 . 



The information flows belonging to service A2 are: 

• A2Auth (ra) 

• A2AuthResult (ra) 

• A21ntermediateResultRequest (rb) 



7.8 



Information flows 



7.8.1 



Definition of information flows 



7.8.1.1 



Relationship ra 



7.8.1.1.1 



A2Auth 



A2Auth is a confirmed information flow that shall be sent across relation ra from FEl to FE2 to indicate a request for 
authentication. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


Challenge 




M 


- 


Response 




- 


M 


Seed 




- 


M 



A2Auth_req_ind ::= SEQUENCE 

{ 

userld AuthenticIdType, 

challenge ChallengeType 



A2Auth_resp_conf ::= SEQUENCE 

{ 

response ResponseType, 
seed SeedType 
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7.8.1.1.2 



A2AuthResult 



A2AuthResult is an unconfirmed information flow that shall be sent across relation ra from FEl to FE2 to indicate the 
result of an authentication. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


Result 


Success 
Fail 


M 


- 



A2AuthResult_req_ind 
{ 



SEQUENCE 



userld 

result 



Authentic IdType, 

BOOLEAN — TRUE equals success, FALSE equals fail 



7.9 Information flow sequences 

This clause specifies the information flow sequences for the authentication service. 

NOTE 1 : The information flow sequences are produced with a MSC editor; however, the scenarios are not MSCs 
but information flow sequences as defined in ITU-T Recommendation 1.130 [4]. 

NOTE 2: In accordance with the ITU-T Recommendation 1.130 [4] the invoking side is placed as the leftmost entity 
in the information flow sequences. 

The step D for authentication shall provide signalling procedures in support of the information flow sequences specified 
in this clause. In addition, signalling procedures should be provided to cover other sequences arising from error 
situations, interactions with simple call, interactions with registration, different topologies, etc. 

In the information flow sequences, authentication information flows are represented by arrows. 

The following information flow sequences are intended as guidance in further development. 
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7.9.1 Information flow in A2, normal behaviour 



MSC A2 


th_req_ind 












FE1 


FE2 


FE4 


FES 






A2Au 
















(Userld, Challenge) 


A2lntermediateResult_req_ind 


(Userld, challenge) 






A2lntermediateResult_resp 


_conf 










(IntermediateResult) 




207 
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(Response, Seed) 






106 








A2Au 


thResult_req_ind 




(Resu 


t) 

































Figure 13: Authentication service A2 information flows 

7.9.2 Functional entity actions 

Throughout the descriptions of FE actions, the following conventions are used to identify information flows: 

An information flow is referred to as a "request" at the FE that sends it and as an "indication" at the FE that 
receives it. 

The corresponding confirmation is referred to as a "response" at the FE that sends it and as a "confirmation" at 
the FE that receives it. 

The following FE actions shall occur at the points indicated in the information flow sequences of clause 7.9.1. 
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7.9.2.1 Actions of A2-FE1 

101 A2-FE1 shall generate a random challenge and send it to A2-FE2. 

102 A2-FE1 generate the intermediate result Intermediate-Result from algorithm A2-1 using the 
random challenge and K-A2 as inputs. 

103 Upon receipt the terminal shall generate the expected cryptographic response using the received 
random seed and the pre-determined Intermediate-Result with algorithm A2-2. In addition A2-2 
should generate an encryption key derived in this exchange for use in later confidentiality services. 

104 The terminal shall compare the expected cryptographic response and the received response, if they 
are the same the authentication centre has proven knowledge of K-A2. 

7.9.2.2 Actions of A2-FE2 

201 A2-FE2 shall generate the intermediate result Intermediate-Result from algorithm A2-1 using the 
random challenge and K-A2 as inputs. 

202 A2-FE2 shall generate a random seed for the second stage of the authentication exchange. 

203 A2-FE2 shall generate the cryptographic response response using algorithm A2-2 with inputs seed 
and Intermediate-Result. 

204 A2-FE2 shall send the random seed and the response to A2-FE1. 

7.9.2.3 Actions of A2-FE3 

301 A2-FE3 shall identify K-Al based on the identity received from A2-FE2 and using the challenge 
received from A2-FE2 as input to algorithm Al-1 with K-Al shall generate Intermediate-Result. 

302 A2-FE3 shall send Intermediate-Result to A2-FE1 using information flow 
A2ChallengeRequest_resp_conf. 

7.9.3 Allocation of functional entities to domains 

The possible allocation of FEs to TIPHON is shown in table 3. 

Table 3: Allocation of FEs to TIPHON domains 



Scenario 


A2-FE1 


A2-FE2 


A2-FE3 


1 


Terminal 


Home Service provider 


Home Service provider 


2 


Terminal 


Visited Service provider 


Home Service provider 


3 


Access network (terminal proxy) 


Home Service provider 


Home Service provider 


4 


Access network (terminal proxy) 


Visited Service provider 


Home Service provider 



8 



A3 and A4, A34 = Mutual authentication terminal and 
SpoA 



8.1 Purpose 



To prevent masquerade of a terminal to a SpoA by providing authentication through a mutual trusted third party (the 
registrar). 

NOTE: The mechanism defined in this clause is optimized for symmetric keying methods but may employ 
asymmetric keying methods with no change in the affect of the countermeasure. 
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8.2 



Definition 



In order to offer service to the terminal the terminal shall be authenticated by the SpoA. This authentication shall be 
based upon information given by the registrar as a result of services Al, A2, A5 and A6 and from the access control 
service CI described in TS 101 882-2. 



8.3 Description 



NOTE: The mechanism here is similar to the 5 pass mutual authentication method described in clause 6.2 of 
ISO/IEC 9798-2 [5]. 

There can be no explicit challenge response protocol between the terminal and the SpoA as there is no shared secret 
knowledge. 

The registrar acts as a trusted party to both the SpoA and to the terminal. The registrar shall generate a random session 
key K34 and distribute this to the SpoA and terminal in a secure manner. 

The registrar shall prepare two packages containing K34 sealed by respectively the secret key K associated with the 
terminal, and the secret key Ks associated with the SpoA. On receipt of the appropriate package the SpoA and the 
Terminal shall be able to recover the session key K34. Authentication of the SpoA and the terminal is provided by using 
the received session key (K34) to encrypt random data generated by each party. 

Authentication 
Centre 



SpoA 






RSO 


RSO 


Ks 
1 




RSO Ks 

V i 


V 1 


A34-1 


Rand K34 

1 1^ 


SealK 
f 


A34-1 


SK34 


SealK 


SK34, Rand 


A34-2 


< 


SK34 


A34-3 


7 1 i 

IVIF K34 Rand 










1 



NOTE: Ks, as input to A34-1 , should be equal to K-A2. 

Figure 14: Distribution of a session l<ey to SpoA 

The first pass shown here uses algorithm A34-1 to generate a sealing key (SealK) from Ks and a Random Seed (RSO). 
The session key, K34, is sealed using algorithm A34-2 with inputs K34, SealK and a random number (Rand). The 
sealed key and the random number are sent to the SpoA which generates SealK using A34-1 and then unseals K34 
using algorithm A34-3. 

The first pass will conventionally be assigned to the authentication centre holding Ks, with the session key being 
generated locally at the registrar. This mitigates against an attack on the authentication centre being able to determine 
the session key in use, and also mitigates against an attack on the registrar being able to determine the shared secrets of 
either Terminal or SpoA. 
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Authentication 
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Terminal 
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NOTE: K, as input to A34-4, should be equal to K-A1 . 

Figure 15: Distribution of a session Itey to terminal 

The first pass shown here uses algorithm A34-4 to generate a sealing key (SealK') fi^om K and a Random Seed (RSO'). 
The session key, K34, is sealed using algorithm A34-5 with inputs K34, SealK' and a random number (Rand'). The 
sealed key and the random number are sent to the terminal which generates SealK' using A34-4 and then unseals K34 
using algorithm A34-6. 

8.3.1 Overall authentication exchange 

The authentication exchange is summarized here: 

1) The terminal creates a random number RSO' and sends it to the SpoA as a challenge. 

2) The SpoA creates its own random number RSO and sends it to the registrar along with RSO' and the identity 
of the terminal. 

3) The registrar requests the sealing keys fi^om the authentication centre by sending RSO, RSO', and the identities 
of the SpoA and Terminal to the authentication centre. 

4) The authentication centre runs algorithms A34-1 and A34-4 to generate SealK and SealK' respectively which 
are returned to the registrar. 

5) The registrar creates the cryptographic token T34-A and sends it to the SpoA. 

6) The SpoA recovers the session key K34 from token T34-A and creates token T34-B which it sends to the 
terminal. 

7) The terminal recovers session key K34 from token T34-B and creates token T34-C which it sends to the SpoA. 
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8.3.1.1 Token definitions 

The following cryptographic tokens are defined: 

T34-A = eKs(RSOIIK34llTerminal-id) II eKT(RSO'IIK34llSpoA-id) 

T34-B = eKT(RSO'IIK34llSpoA-id) II eK34(RSOIIRSO') 

T34-C = eK34(RSOIIRSO'IIClientAuthorizationToken) 

NOTE: In each case the cryptographic tokens can be extended using arbitrary text fields but for clarity this is not 
shown. 

Algorithm A34-4 in conjunction with A34-5, and algorithm A34-1 in conjunction with A34-2, provide the two halves of 
T34-A which allows the token definitions to be rewritten as: 

T34-A = Output: (A34-2) II Output l(A34-5) 

T34-B = Output: (A34-5) II eK34(RSOIIRSO') 

In addition an algorithm, A34-7, is defined to provide CryptoElement: 

CryptoElement = eK34(RSOIIRSO') 



Client Authoris ationToken 



RSO RSO' 



K34 



SK34' 



SK34 




Figure 16: Algorithms to derive toitens T34-A, T34-B and T34-C 

Allowing T34-B to be rewritten as: 

T34-B = Output: (A34-5) II Output: (A34-7) 

The CryptoElement is created by the SpoA and contains data from the terminal and random data from the SpoA. These 
are encrypted with the shared key K34. On receipt of CryptoElement at the terminal the two data elements are 
recovered. If the random data from the terminal matches that already given then the terminal is assured that the SpoA 
has the data and has K34 so the terminal has been able to authenticate that the SpoA is known to the trusted party. 
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8.4 Procedures 

8.4.1 Provision/withdrawal 

Authentication shall always be available. 

8.4.2 Normal procedures 

Authentication shall always be activated. 

8.4.2.1 Invocation and operation 

Authentication may be invoked on one or more of the following events: 
on registration to TIPHON™; 
on change of physical point of attachment; 
on change of logical point of attachment; 
on demand by the user through some terminal function; and 
on demand by the authentication centre. 

8.4.3 Exceptional procedures 

8.4.3.1 Activation/deactivation/registration/interrogation 

Not applicable. 

8.4.3.2 Invocation and operation 

See clause 8.3. 

8.5 Interactions with other TIPHON services 

The authentication services are linked to the registration service and shall be operated in parallel to them. 
The authentication services shall provide keying material for the confidentiality services El, E2 and E7. 
The authentication services shall provide the basis for the access control service CI. 

8.6 Interworking considerations 

The authentication algorithms used by each of the participant entities have to be matched. 
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8.7 Functional entity model 
8.7.1 Description of model 

Figure 16 shows the FEs and the relationships between them. 




Figure 17: Relationships between functional entities for authentication service A34 



Where: 



A34-FE1 



Agent at terminal that initiates authentication, contains algorithms A34-4 and A34-6. 



A34-FE2 



Agent representing the SpoA holds algorithms A34-1 and A34-3. 



A34-FE3 



Agent representing the Registrar (Trusted Third Party), contains algorithms A34-2 and A34-5. 



A34-FE4 



Agent representing the Authentication Centre, contains algorithms A34-1 and A34-4. 



The information flows between A34-FE2, A34-FE3 and A34-FE4 are required to supply A34-FE2 with the session key 
to be shared with A34-FE1. 

The information flows belonging to service A34 are: 

• A34UserToSpoAAuth (ra) 

• A34UserToSpoAAuthorizedAttach (ra) 

• A34SpoAWithUserAuth (rb) 

• A34SealingKeyRequest (re) 
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8.8 



Information flows 



8.8.1 Definition of information flows 



8.8.1.1 



Relationship ra 



8.8.1.1.1 



A34UserToSpoAAuth 



A34UserToSpoAAuth is a confirmed information flow sent across relation ra from FEl to FE2 to initiate the exchange 
of session key K34. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


RSO' (AccessChallenge) 




M 


- 


T34-B 




- 


M 



8.8.1.1.2 



A34UserToSpoAAuthorizedAttach 



A34UserToSpoAAuthorizedAttach is an unconfirmed information flow sent across relation ra from FEl to FE2 to 
finalize the SpoA/Terminal authentication exchange. 



Information element 


Value 


Request 


Confirmation 


T34-C 




M 


- 



8.8.1.2 



Relationship rb 



8.8.1.2.1 



A34Spo AWith UserAuth 



A34SpoAWithUserAuth is a confirmed information flow sent across relation rb from FE2 to FE3 to initialize the 
SpoA/Terminal authentication exchange. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


- 


SpoA-id 




M 




RSO' (AccessChallenge) 




M 


- 


RSO (SpoA Challenge) 




M 


- 


T34-A 






M 



8.8.1.3 



Relationship re 



8.8.1.3.1 



A34SealingKeyRequest 



A34SealingKeyRequest is a confirmed information flow sent across relation re from FE3 to FE4 to retrieve the keys 
used to seal the session key prior the session key being sent to each of the SpoA and Terminal. 



Information element 


Value 


Request 


Confirmation 


Userld 




M 


M 


SpoA-id 




M 


M 


RSO 




M 


- 


RSO' 




M 


- 


SealK 




- 


M 


SealK' 




- 


M 
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8.9 Information flow sequences 

This clause specifies the information flow sequences for the authentication service. 

NOTE 1 : The information flow sequences are produced with a MSC editor; however, the scenarios are not MSCs 
but information flow sequences as defined in ITU-T Recommendation 1.130 [4]. 

NOTE 2: In accordance with the ITU-T Recommendation 1.130 [4] the invoking side is placed as the leftmost entity 
in the information flow sequences. 

The step D for authentication shall provide signalling procedures in support of the information flow sequences specified 
in this clause. In addition, signalling procedures should be provided to cover other sequences arising from error 
situations, interactions with simple call, interactions with registration, different topologies, etc. 

In the information flow sequences, authentication information flows are represented by arrows. 

The following information flow sequences are intended as guidance in further development. 
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8.9.1 Information flow in A3, normal behaviour 



MSC A34 



A34UserToSpoAAuth_req_ind 



(Userld, RSOprime ) 



A34SpoAWithUs erAuthreqJ nd 



(Userld, SpoA-id, RSO, RSOprime 



A34SealingKeyRequest_req_ind 
(Userld, SpoA-id, RSO, RSOprime 



A34SealingKeyRequest_resp_conf 



Userld, SpoA-id, SealK, SealKprime) 



A34SpoAWithUserAuth_resp_conf 




( T34-A) 



A34UserToSpoAAuth_resp_conf 



( T34-B) 



A34UserToSpoAAuthorisedAttach_reqJnd 



(T34-C ) 



Figure 18: Authentication service A34 information flows 
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8.9.2 Functional entity actions 

Throughout the descriptions of FE actions, the following conventions are used to identify information flows: 

An information flow is referred to as a "request" at the FE that sends it and as an "indication" at the FE that 

receives it. 

The corresponding confirmation is referred to as a "response" at the FE that sends it and as a "confirmation" at 
the FE that receives it. 

The following FE actions shall occur at the points indicated in the information flow sequences of clause 8.9.1. 

8.9.2.1 Actions of A34-FE1 

101 A34-FE1 shall generate a random seed, RSO'. 

102 Using A34UserToSpoAAuth-request A34-FE1 shall send RSO' as a challenge to A34-FE2 to 
initiate the authentication. 

103 Using RSO' and K as input to A34-4 A34-FE1 shall generate SealK'. 

104 Using SealK' from action 103 and SK34' (recovered from T34-B) from 
A34UserToSpoAAuth_resp_conf as inputs to A34-6 A34-FE1 shall recover K34 and Rand'. The 
Rand' recovered with A34-6 and Rand' received in A34UserToSpoAAuth_resp_conf shall be 
compared and if no errors exist they should be found equal. 

105 Generates token T34-C using algorithm A34-9 and sends it to A34-FE2 using the 
A34UserToSpoAAuthorizedAttach-req-ind information flow. 

8.9.2.2 Actions of A34-FE2 

201 On receipt of A34UserToSpoAAuth-req-ind A34-FE2 shall extend the authentication by 
generating its own challenge RSO. 

202 Using A34SpoAWithUserAuth-req-ind A34-FE2 shall send the challenges to A34-FE3. 

203 On receipt of A34SpoAWithUserAuth-resp-conf A34-FE2 extracts A34 from T34-A using 
algorithm A34-3. 

204 Using algorithm A34-8 and the FEl part of T34-A A34-FE2 constructs token T34-B and sends it 
to A34-FE1 using the A34UserToSpoAAuth-resp-conf information flow. 

205 On receipt of T34-C from the A34UserToSpoAAuthorizedAttach-req-ind information flow 
A34-FE2 shall confirm that RSO has the correct value and ensure that the 
ClientAuthorizationToken correctly identifies the client and service. 

8.9.2.3 Actions of A34-FE3 

301 On receipt of the challenges A34-FE3 shall forward them to the A34-FE4 using the 
A34SealingKeyRequest-req-ind information flow. 

302 On receipt of A34SealingKeyRequest-resp-conf A34-FE3 shall extract the sealing keys SealK and 
SealK'. 

303 A34-FE3 shall generate counter challenges Rand and Rand', using them with SealK and SealK' to 
seal K34 using algorithms A34-2 and A34-4 respectively. 

304 A34-FE3 shall construct token A34-A from the outputs of A34-2 and A34-4 and send the token to 
A34-FE3 using the A34SpoAWithUserAuth-resp-conf information flow. 
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8.9.2.4 Actions of A34-FE4 

401 From User-id identifies K, and generates SealK' using K and RSO' as inputs to algorithm A34-4. 

402 From SpoA-id identifies Ks, and generates SealK using Ks and RSO as inputs to algorithm A34-1. 

403 Sends SealK and SealK' to A34-FE3 using information flow A34SealingKeyRequest-resp-conf 

9 A5 = Authentication of the SpoA by the registrar 

See description of Al. 

10 A6 = Authentication of the registrar by the SpoA 

See description of A2. 



1 1 Confidentiality service 

The confidentiality services in TIPHON are optional services, but where provided shall be provided as described in the 
present document. 

11.1 Provided services 

11.1.1 El = Confidentiality of user communication on the access interface 

Encryption on the access interface for outgoing and incoming calls, and for subscription registration procedure can 
provide confidentiality to the user communication and to TIPHON signalling. 

This service lies between the user terminal and the SpoA/TpoA in the transport domain. 

1 1 .1 .2 E2 = Confidentiality of signalling on the access interface 

The signalling can be protected on the access interface. Possible solutions include the use of encryption. 
This service lies between the user terminal and the SpoA/TpoA in the service domain. 

1 1 .1 .3 E3 = Confidentiality of signalling between SpoA entities 

Security and other sensitive data such as session keys, call-forwarding number, and personal data can be protected by a 
number of mechanisms. Encryption is one such mechanism. 

This service lies between SpoAs in the service domain. 

1 1 .1 .4 E6 = Confidentiality of TIPHON-id on signalling interfaces 

The TlPHON-id can be protected on signalling interfaces. This may be protected by use of an alias-id or by encryption 
of signalling. 
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11 .1 .5 E7 = Confidentiality of signalling between SpoA and Registrar 

NOTE: E7 is considered as a special case of E3. 

The link between SpoA and Registrar identifies the user of the service and may identify the key to be used in service 

E2. 

This service lies between SpoA and registrar (special case of SpoA) in the service domain. 

1 1 .2 Confidentiality services El and E2 step B specification 
11.2.1 Description 

The confidentiality services El and E2 are provisioned by use of an encryption service that lies between the service 
encoding unit and the transport service. This means that any transport service will be able to carry the encrypted Service 
Data Unit. 



Message variant parameters 
Time variant parameters 
Key 



Service Encoding 
and Logic 



c> 



)l 



Encryption device 



Transport 



Service Encoding 
and Logic 



TV 



Signalling or traffic to be protected 



Message variant parameters 
Time variant parameters 
Key 



^ 



1 



Encryption device 



Transport 



Figure 19: Location of encryption in generic TIPIHGN model 

The encryption device shall be a streaming cipher device operating in a bit replacement mode (i.e. every bit of plaintext 
is replaced with a bit of ciphertext). 

The SpoA should only have one encryption algorithm. A terminal may have more than one algorithm but shall use the 
algorithm indicated by the SpoA at the time of registration. 



CK 



Direction 



Length 
TVP - 



Plaintext/Ciphertext 




KSS 



Ciphertext/Plaintext 



CK: 
KSG 
KSS 
TVP: 



Cipher Key 

Key Stream Generator 
Key Stream Segment 
Time Variant Parameter 



Figure 20: Speech and control information encryption 
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1 1 .2.2 Encryption mechanism 



The KSS bits shall be modulo 2 added (XORed) with plain text bits in traffic and signalling Service Data Units (SDUs) 
to obtain encrypted cipher text bits. KSS(O) shall be XORed with the first transmitted bit of the first SDU, and so on. 
Any unused bits of KSS shall be discarded. 

1 1 .3 Confidentiality services E3 and E7 step B specification 
11.3.1 Description 

The confidentiality services E3 and E7 are provisioned by means of an encryption service that lies between the service 
encoding unit and the transport service. This means that any transport service will be able to carry the encrypted Service 
Data Unit. 

In the case of service E3 there can be no guarantee of a pre-provisioned encryption key (or other secret). In this instance 
some form of zero-knowledge secure exchange may be required. 

In the case of service E7 a crypto-key is made available as a direct result of authentication services A5 and A6. This key 
should be used to encrypt any signalling between SpoA and registrar. Where both A5 and A6 have been invoked as part 
of a mutual authentication the key to be used for encryption should be created as a cryptographic product of the 
individual cipher keys. E7 shall use an encryption algorithm EA7 (Encryption Algorithm for service E7) defined by its 
boundary conditions. 

1 1 .3.1 .1 Algorithm requirements for EA7 

The security shall be maintained for "n" messages. 

NOTE: SAGE to assist in the definition of EA7 and of "n". 
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Annex A (normative): 

Boundary conditions of algorithms 

A.1 Authentication algorithms 

A.1.1 AM 

Al-1: shall be used to compute Intermediate Response from K and Challenge. The algorithm shall have the following 
properties: 

Input 1: Bit string of length IKI; 

Input 2: Bit string of length IChallengel; 

Output: Bit string of length llntermediate Response!. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output (even if the details of the algorithm are known). 

A.1.2 A1-2 

Al-2: shall be used to compute (X)Response as well as CryptoKey from Intermediate Response and Seed. The 
algorithm shall have the following properties: 

Input 1: Bit string of length llntermediate Response!; 

Input 2: Bit string of length ISeedl; 

Output 1: Bit string of length l(X)Responsel; 

Output 2: Bit string of length ICryptoKeyl. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 or Output 2 from the 
knowledge of Input 2 and Output 1 (even if the details of the algorithm are known). 

A.1.3 A1-3 

Al-3: shall be used to compute Result by bit comparison of Xresponse and Response. Al-3 has no special 
cryptographic properties. 

A.1.4 A2-1 

A2-1: shall be used to compute IntermediateResponse from K and Challenge. The algorithm shall have the following 
properties: 

Input 1: Bit string of length IKI; 

Input 2: Bit string of length IChallengel; 

Output: Bit string of length llntermediateResponsel. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output (even if the details of the algorithm are known). 
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A.1.5 A2-2 



A2-2: shall be used to compute (X)Response as well as CryptoKey from IntermediateResponse and Seed. The 
algorithm shall have the following properties: 

Input 1: Bit string of length llntermediateResponsel; 

Input 2: Bit string of length ISeedl; 

Output 1: Bit string of length l(X)Responsel; 

Output 2: Bit string of length ICryptoKeyl. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 or Output 2 from the 
knowledge of Input 2 and Output 1 (even if the details of the algorithm are known). 

A.1.6 A2-3 

A2-3: shall be used to compute Result by bit comparison of Xresponse and Response. A2-3 has no special 
cryptographic properties. 

A.1.7 A34-1 

A34-1: shall be used to compute SealK from Kg and RSO. The algorithm shall have the following properties: 

Input 1 : Bit string of length I K§ I; 

Input 2: Bit string of length IRSOI; 

Output 1: Bit string of length ISealKI. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from knowledge of 
input 2 and the output (even if details of the algorithm are known). 

A. 1.8 A34-2 

A34-2: shall be used to compute SK34 from K34, Rand, and SealK. The algorithm shall have the following properties: 

Input 1 : Bit string of length IK34I; 

Input 2: Bit string of length IRandl; 

Input 3: Bit string of length ISealKI; 

Output: Bit string of length ISK34I. 

The algorithms should be designed such that it is difficult to infer any information about Input 1 or Input 3 from the 
knowledge of Input 2 and the Output, provided that Input 3 is unknown (even if the details of the algorithm are known). 

A. 1.9 A34-3 

A34-3: shall be used to compute K34 and Rand from SK34 and SealK. The algorithm shall have the following 
properties: 

Input 1 : Bit string of length ISK34I; 

Input 2: Bit string of length ISealKI; 

Output 1: Bit string of length IK34I; 

Output 2: Boolean; 
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Output 3: Bit string of length IRandl. 



The algorithm should be designed such that it is difficult to find for a fixed Input 2 values for Input 1 that result in 
Output 2 assuming the value FALSE, provided that Input 2 is unknown (even if the details of the algorithm are known). 
Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values of other 
inputs and outputs (known plain text attack). 

A. 1.10 A34-4 

A34-4: shall be used to compute SealK' from K and RSO'. The algorithm shall have the following properties: 

Input 1 : Bit string of length I Kl; 

Input 2: Bit string of length IRSO'I; 

Output 1: Bit string of length ISealK'l. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from knowledge of 
input 2 and the output (even if details of the algorithm are known). 

A. 1.11 A34-5 

A34-5: shall be used to compute SK34' from K34, Rand', and SealK'. The algorithm shall have the following properties: 

Input 1 : Bit string of length IK34I; 

Input 2: Bit string of length IRand'l; 

Input 3: Bit string of length ISealK'l; 

Output: Bit string of length ISK34'I. 

The algorithms should be designed such that it is difficult to infer any information about Input 1 or Input 3 from the 
knowledge of Input 2 and the Output, provided that Input 3 is unknown (even if the details of the algorithm are known). 

A. 1.1 2 A34-6 

A34-6: shall be used to compute K34 and Rand' from SK34' and SealK'. The algorithm shall have the following 
properties: 

Input 1 : Bit string of length ISK34'I; 

Input 2: Bit string of length ISealK'l; 

Output 1: Bit string of length IK34I; 

Output 2: Boolean; 

Output 3: Bit string of length IRand'l. 

The algorithm should be designed such that it is difficult to find for a fixed Input 2 values for Input 1 that result in 
Output 2 assuming the value FALSE, provided that Input 2 is unknown (even if the details of the algorithm are known). 
Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values of other 
inputs and outputs (known plain text attack). 
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A. 1.1 3 A34-7 

A34-7: shall be used to compute CryptoElement from RSO, RSO' and K34. The algorithm shall have the following 
properties: 

Input 1 : Bit string of length IRSOI; 

Input 2: Bit string of length IRSO'I; 

Input 3: Bit string of length IK34I; 

Output 1 : Bit string of length ICryptoElementl. 

The algorithm should be designed such that it is difficult to infer any information about Input 3 from the knowledge of 
the other inputs and the Output (even if the details of the algorithm are known). 

A. 1.1 4 A34-8 

A34-8: shall be used to compute token T34-A from SK34' and SK34. A34-8 has no special cryptographic properties. 

A. 1.1 5 A34-9 

A34-9: shall be used to compute token T34-B from SK34' and CryptoElement. A34-9 has no special cryptographic 
properties. 

A.I. 16 A34-10 

A34-10: shall be used to compute token T34-C from RSO, RSO', K34 and the ClientAuthorizationToken. The 
algorithm shall have the following properties: 

Input 1 : Bit string of length IRSOI; 

Input 2: Bit string of length IRSO'I; 

Input 3: Bit string of length IK34I; 

Input 4: Bit string of length IClientAuthorizationTokenI; 

Output 1: Bit string of length IT34-CI. 

The algorithm should be designed such that it is difficult to infer any information about Input 3 from the knowledge of 
the other inputs and the Output (even if the details of the algorithm are known). 



A.2 Dimensioning of the cryptographic parameters 

Table A.l shows the lengths of the cryptographic parameters given in annex A. 

Table A.l : Dimensioning of cryptographic parameters 



Abbreviation 


No. of Bits 


K 


196 


Intermediate result 


196 


Challenge 


128 


Response 


128 


Seed 


128 


CryptoKey 


128 
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A.2.1 Terminal-identity 



The terminal identity used is required to uniquely identify the authentication key. In cases where access to the 
authentication key is required globally then the terminal identity is required to be globally unique. 



A.3 Encryption algorithms 

A.3.1 EM 2 - Confidentiality algorithm 
A.3. 1.1 Overview 

The input parameters to the algorithm are the Cipher Key (CK), a Time Dependent Input (TVP), the direction of 
transmission (DIRECTION) and the length of the keystream required (LENGTH). Based on these input parameters the 
algorithm generates the output keystream block (KEYSTREAM) which is used to encrypt the input plaintext block 
(PLAINTEXT) to produce the output ciphertext block (CIPHERTEXT). 

The input parameter LENGTH shall affect only the length of the KEYSTREAM block, not the actual bits in it. 

A.3.1. 2 Use 

The function EA12 shall only be used to protect the confidentiality of user data and signalling data as required for 
services El and E2. 

EA12 shall be found in the terminal and in the SpoA. 

A.3. 1 .3 Extent of standardization 

The function EA12 shall be fully standardized. 

A.3.1 .4 Implementation and operational considerations 

The algorithm should be designed to accommodate a range of implementation options including wholly hardware and 
wholly software implementations, and mixed hardware and software implementations. 

A.3. 1.5 Type of algorithm 

The function EA12 should be a symmetric synchronous stream cipher. 



A.3. 1 .6 Interfaces to the algorithm 



A.3. 1.6.1 CK 

CK: the cipher key 

CK[0],CK[1], ...,CK[127] 

The length of CK is 128 bits. In case the effective key length should need to be made smaller than 128 bits, the most 
significant bits of CK shall carry the effective key information, whereas the remaining, least significant bits shall be set 
zero. 

CK should be derived during the authentication cycle and be computed from the combination of the SessionKey outputs 
from authentication services A3 and A4 (i.e. combination of key K34 and K43). 

ASN.l example: CK-Type ::= BIT STRING (SIZE(KeyLength)) 
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A.3.1.6.2 TVP 

TVP: a time dependent input. 

TVP[0],TVP[1], ...,TVP[31] 

The length of the TVP parameter is 32 bits. The exact structure of the TVP parameter is implementation dependent and 
has to be specified in the step D process. 

ASN.l example: TVP-Type ::= BIT STRING (SIZE(TVPLength)) 

A.3.1.6.3 DIRECTION 

DIRECTION: the direction of transmission of the transport to be encrypted. 

DIRECTION [0] 

The length of DIRECTION is 1 bit. The same cipher key may be used for uplink and downlink channels (i.e. from the 
terminal and to the terminal) simultaneously. To avoid using the same keystream to encrypt both uplink and downlink 
transmissions, the algorithm shall generate the keystream based on the direction of transmission. 

An explicit direction value is required in preference to splitting the keystream segment into uplink and downlink 
portions to allow for asymmetric bearer services. 

ASN.l example: Direction-Type ::= BIT STRING (SIZE(DirectionLength)) 

A.3.1.6.4 LENGTH 

LENGTH: the required length of keystream. 

LENGTH[0], LENGTH[1], ..., LENGTH[18-1] 

The length of LENGTH is 18 bits. The length of the plaintext block that is transmitted during a single transport frame 
may vary. The algorithm shall generate a keystream block of variable length based on the value of the length parameter. 

The input parameter LENGTH shall affect only the length of the KEYSTREAM block, not the actual bits in it. 

ASN.l example: Length-Type ::= BIT STRING (SIZE(LengthLength)) 

A.3.1.6.5 KEYSTREAM 

KEYSTREAM: the output keystream segment. 

KS [0], KS [1], ..., KS [LENGTH-1] 
The length of a keystream segment block equals the value of the input parameter LENGTH. 

ASN.l example: Keystream-Type ::= BIT STRING (SIZE(Length)) 

A.3.1.6.6 PLAINTEXT 

PLAINTEXT: the plaintext. 

PT[0], PT[1], ..., PT[LENGTH-1] 

The length of a keystream block equals the value of the input parameter LENGTH. 

This plaintext block consists of the payload of the particular PDUs/SDUs to be encrypted in a single transport frame. It 
may consist of user traffic or signalling data. 

ASN.l example: Plaintext-Type ::= BIT STRING (SIZE(Length)) 
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A.3.1.6.7 CIPHERTEXT 

CIPHERTEXT: the ciphertext. 

CT[0], CT[1], ..., CT[LENGTH-1] 
The length of a keystream block equals the value of the input parameter LENGTH. 

ASN.l example: Ciphertext-Type ::= BIT STRING (SIZE(Length)) 
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